home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
QRZ! Ham Radio 8
/
QRZ Ham Radio Callsign Database - Volume 8.iso
/
pc
/
files
/
p_misc
/
netconf.arc
/
KISSTNC.TXT
< prev
next >
Wrap
Text File
|
1988-12-10
|
33KB
|
785 lines
The KISS TNC: A simple Host-to-TNC communications
protocol
Mike Chepponis, K3MC
Phil Karn, KA9Q
_A_B_S_T_R_A_C_T
The KISS[1] TNC provides direct computer to TNC
communication using a simple protocol described here.
Many TNCs now implement it, including the TAPR TNC-1
and TNC-2 (and their clones), the venerable VADCG TNC,
the AEA PK-232/PK-87 and all TNCs in the Kantronics
line. KISS has quickly become the protocol of choice
for TCP/IP operation and multi-connect BBS software.
_1. _I_n_t_r_o_d_u_c_t_i_o_n
Standard TNC software was written with human users in mind;
unfortunately, commands and responses well suited for human use
are ill-adapted for host computer use, and vice versa. This is
especially true for multi-user servers such as bulletin boards
which must multiplex data from several network connections
across a single host/TNC link. In addition, experimentation
with new link level protocols is greatly hampered because there
may very well be no way at all to generate or receive frames in
the desired format without reprogramming the TNC.
The KISS TNC solves these problems by eliminating as much
as possible from the TNC software, giving the attached host com-
plete control over and access to the contents of the HDLC frames
transmitted and received over the air. This is central to the
KISS philosophy: the host software should have control over all
TNC functions at the lowest possible level.
The AX.25 protocol is removed entirely from the TNC, as are
all command interpreters and the like. The TNC simply converts
between synchronous HDLC, spoken on the full- or half-duplex
radio channel, and a special asynchronous, full duplex frame
format spoken on the host/TNC link. Every frame received on the
_________________________
[1]
[1] "Keep It Simple, Stupid"
December 6, 1988
HDLC link is passed intact to the host once it has been
translated to the asynchronous format; likewise, asynchronous
frames from the host are transmitted on the radio channel once
they have been converted to HDLC format.
Of course, this means that the bulk of AX.25 (or another
protocol) must now be implemented on the host system. This is
acceptable, however, considering the greatly increased flexibil-
ity and reduced overall complexity that comes from allowing the
protocol to reside on the same machine with the applications to
which it is closely coupled.
It should be stressed that the KISS TNC was intended only
as a stopgap. Ideally, host computers would have HDLC inter-
faces of their own, making separate TNCs unnecessary. [15]
Unfortunately, HDLC interfaces are rare, although they are
starting to appear for the IBM PC. The KISS TNC therefore
becomes the "next best thing" to a real HDLC interface, since
the host computer only needs an ordinary asynchronous interface.
_2. _A_s_y_n_c_h_r_o_n_o_u_s _F_r_a_m_e _F_o_r_m_a_t
The "asynchronous packet protocol" spoken between the host
and TNC is very simple, since its only function is to delimit
frames. Each frame is both preceded and followed by a special
FEND (Frame End) character, analogous to an HDLC flag. No CRC
or checksum is provided. In addition, no RS-232C handshaking
signals are employed.
The special characters are:
____________________________________________________
Abbreviation Description Hex value
________________________________________________________________________________________________________
FEND Frame End C0
FESC Frame Escape DB
TFEND Transposed Frame End DC
TFESC Transposed Frame Escape DD
____________________________________________________
||||||
||||||
The reason for both preceding and ending frames with FENDs
is to improve performance when there is noise on the asynch
line. The FEND at the beginning of a frame serves to "flush
out" any accumulated garbage into a separate frame (which will
be discarded by the upper layer protocol) instead of sticking it
on the front of an otherwise good frame. As with back-to-back
flags in HDLC, two FEND characters in a row should not be inter-
preted as delimiting an empty frame.
_3. _T_r_a_n_s_p_a_r_e_n_c_y
Frames are sent in 8-bit binary; the asynchronous link is
set to 8 data bits, 1 stop bit, and no parity. If a FEND ever
December 6, 1988
appears in the data, it is translated into the two byte sequence
FESC TFEND (Frame Escape, Transposed Frame End). Likewise, if
the FESC character ever appears in the user data, it is replaced
with the two character sequence FESC TFESC (Frame Escape, Tran-
sposed Frame Escape).
As characters arrive at the receiver, they are appended to
a buffer containing the current frame. Receiving a FEND marks
the end of the current frame. Receipt of a FESC puts the
receiver into "escaped mode", causing the receiver to translate
a following TFESC or TFEND back to FESC or FEND, respectively,
before adding it to the receive buffer and leaving escaped mode.
Receipt of any character other than TFESC or TFEND while in
escaped mode is an error; no action is taken and frame assembly
continues. A TFEND or TESC received while not in escaped mode
is treated as an ordinary data character.
This procedure may seem somewhat complicated, but it is
easy to implement and recovers quickly from errors. In particu-
lar, the FEND character is never sent over the channel except as
an actual end-of-frame indication. This ensures that any intact
frame (properly delimited by FEND characters) will always be
received properly regardless of the starting state of the
receiver or corruption of the preceding frame.
This asynchronous framing protocol is identical to "SLIP"
(Serial Line IP), a popular method for sending ARPA IP datagrams
across asynchronous links. It could also form the basis of an
asynchronous amateur packet radio link protocol that avoids the
complexity of HDLC on slow speed channels.
_4. _C_o_n_t_r_o_l _o_f _t_h_e _K_I_S_S _T_N_C
Each asynchronous data frame sent to the TNC is converted
back into "pure" form and queued for transmission as a separate
HDLC frame. Although removing the human interface and the AX.25
protocol from the TNC makes most existing TNC commands unneces-
sary (i.e., they become host functions), the TNC is still
responsible for keying the transmitter's PTT line and deferring
to other activity on the radio channel. It is therefore neces-
sary to allow the host to control a few TNC parameters, namely
the transmitter keyup delay, the transmitter persistence vari-
ables and any special hardware that a particular TNC may have.
To distinguish between command and data frames on the
host/TNC link, the first byte of each asynchronous frame between
host and TNC is a "type" indicator. This type indicator byte is
broken into two 4-bit nibbles so that the low-order nibble indi-
cates the command number (given in the table below) and the
high-order nibble indicates the port number for that particular
command. In systems with only one HDLC port, it is by defini-
tion Port 0. In multi-port TNCs, the upper 4 bits of the type
indicator byte can specify one of up to sixteen ports. The fol-
lowing commands are defined in frames to the TNC (the "Command"
December 6, 1988
field is in hexadecimal):
________________________________________________________________
Command Function Comments
________________________________________________________________________________________________________________________________
0 Data frame
The rest of the
frame is data to
be sent on the
HDLC channel.
________________________________________________________________
1 TXDELAY
The next byte is
the transmitter
keyup delay in
10 ms units.
The default
start-up value
is 50 (i.e., 500
ms).
________________________________________________________________
2 P
The next byte is
the persistence
parameter, p,
scaled to the
range 0 - 255
with the follow-
ing formula:
_P=_p*256-1
The default
value is P = 63
(i.e., p =
0.25).
________________________________________________________________
3 SlotTime
The next byte is
the slot inter-
val in 10 ms
units. The
default is 10
(i.e., 100ms).
________________________________________________________________
4 TXtail
The next byte is
the time to hold
up the TX after
the FCS has been
sent, in 10 ms
units. This
command is
obsolete, and is
included here
only for compa-
tibility with
some existing
implementations.
________________________________________________________________
December 6, 1988
5 FullDuplex
The next byte is
0 for half
duplex, nonzero
for full duplex.
The default is 0
(i.e., half
duplex).
________________________________________________________________
6 SetHardware
Specific for
each TNC. In
the TNC-1, this
command sets the
modem speed.
Other implemen-
tations may use
this function
for other
hardware-
specific func-
tions.
________________________________________________________________
FF Return
Exit KISS and
return control
to a higher-
level program.
This is useful
only when KISS
is incorporated
into the TNC
along with other
applications.
________________________________________________________________
|||||||||||||||||||||||||||||||
|||||||||||||||||||||||||||||||
The following types are defined in frames to the host:
________________________________________________________________
Type Function Comments
________________________________________________________________________________________________________________________________
0 Data frame
Rest of frame is
data from the
HDLC channel
________________________________________________________________
|||||
|||||
No other types are defined; in particular, there is no pro-
vision for acknowledging data or command frames sent to the TNC.
KISS implementations must ignore any unsupported command types.
All KISS implementations must implement commands 0,1,2,3 and 5;
the others are optional.
_5. _B_u_f_f_e_r _a_n_d _P_a_c_k_e_t _S_i_z_e _L_i_m_i_t_s
One of the things that makes the KISS TNC simple is the
deliberate lack of TNC/host flow control. The host computers run
a higher level protocol (typically TCP, but AX.25 in the con-
nected mode also qualifies) that handles flow control on an
December 6, 1988
end-to-end basis. Ideally, the TNC would always have more
buffer memory than the sum of all the flow control windows of
all of the logical connections using it at that moment. This
would allow for the worst case (i.e., all users sending simul-
taneously). In practice, however, many (if not most) user con-
nections are idle for long periods of time, so buffer memory may
be safely "overbooked". When the occasional "bump" occurs, the
TNC must drop the packet gracefully, i.e., ignore it without
crashing or losing packets already queued. The higher level
protocol is expected to recover by "backing off" and retransmit-
ting the packet at a later time, just as it does whenever a
packet is lost in the network for any other reason. As long as
this occurs infrequently, the performance degradation is slight;
therefore the TNC should provide as much packet buffering as
possible, limited only by available RAM.
Individual packets at least 1024 bytes long should be
allowed. As with buffer queues, it is recommended that no
artificial limits be placed on packet size. For example, the
K3MC code running on a TNC-2 with 32K of RAM can send and
receive 30K byte packets, although this is admittedly rather
extreme. Large packets reduce protocol overhead on good chan-
nels. They are essential for good performance when operating on
high speed modems such as the new WA4DSY 56 kbps design.
_6. _P_e_r_s_i_s_t_e_n_c_e
The P and SlotTime parameters are used to implement true
p-persistent CSMA. This works as follows:
Whenever the host queues data for transmission, the TNC
begins monitoring the carrier detect signal from the modem. It
waits indefinitely for this signal to go inactive. When the
channel clears, the TNC generates a random number between 0 and
1.[2] If this number is less than or equal to the parameter _p,
the TNC keys the transmitter, waits .01 * TXDELAY seconds, and
transmits all queued frames. The TNC then unkeys the transmitter
and goes back to the idle state. If the random number is
greater than _p, the TNC delays .01 * SlotTime seconds and
repeats the procedure beginning with the sampling of the carrier
detect signal. (If the carrier detect signal has gone active in
the meantime, the TNC again waits for it to clear before con-
tinuing). Note that _p=1 means "transmit as soon as the channel
_________________________
[2] To conform to the literature, here _p takes on
values between 0 to 1. However, fractions are difficult
to use in a fixed point microprocessor so the KISS TNC
actually works with _P values that are rescaled to the
range 0 to 255. To avoid confusion, we will use
lower-case _p to mean the former (0-1) and upper-case _P
whenever we mean the latter (0-255).
December 6, 1988
clears"; in this case the p-persistence algorithm degenerates
into the 1-persistent CSMA generally used by conventional AX.25
TNCs.
p-persistence causes the TNC to wait for an exponentially-
distributed random interval after sensing that the channel has
gone clear before attempting to transmit. With proper tuning of
the parameters _p and SlotTime, several stations with traffic to
send are much less likely to collide with each other when they
all see the channel go clear. One transmits first and the oth-
ers see it in time to prevent a collision, and the channel
remains stable under heavy load. See references [1] through
[13] for details.
We believe that optimum _p and SlotTime values could be com-
puted automatically. This could be done by noting the channel
occupancy and the length of the frames on the channel. We are
proceeding with a simulation of the p-persistence algorithm
described here that we hope will allow us to construct an
automatic algorithm for _p and SlotTime selection.
We added p-persistence to the KISS TNC because it was a
convenient opportunity to do so. However, it is not inherently
associated with KISS nor with new protocols such as TCP/IP.
Rather, persistence is a _c_h_a_n_n_e_l _a_c_c_e_s_s protocol that can yield
dramatic performance improvements regardless of the higher level
protocol in use; we urge it be added to _e_v_e_r_y TNC, whether or
not it supports KISS.
_7. _I_m_p_l_e_m_e_n_t_a_t_i_o_n _H_i_s_t_o_r_y
The original idea for a simplified host/TNC protocol is due
to Brian Lloyd, WB6RQN. Phil Karn, KA9Q, organized the specifi-
cation and submitted an initial version on 6 August 1986. As of
this writing, the following KISS TNC implementations exist:
_________________________________________________________________
TNC type Author Comments
__________________________________________________________________________________________________________________________________
TAPR TNC-2 & clones Mike Chepponis, K3MC
First implemen-
tation, most
widely used.
Exists in both
downloadable and
dedicated ROM
versions.
_________________________________________________________________
TAPR TNC-1 & clones Marc Kaufman, WB6ECE
Both download
and dedicated
ROM versions.
_________________________________________________________________
VADCG TNC & Ashby TNC Mike Bruski, AJ9X Dedicated ROM.
_________________________________________________________________
December 6, 1988
AEA PK-232 & PK-87 Steve Stuart, N6IA
Integrated into
standard AEA
firmware as of
21 January 1987.
The special com-
mands "KISS ON"
and "KISS OFF"
(!) control
entry into KISS
mode.
_________________________________________________________________
Kantronics Mike Huslig
Integrated into
standard Kan-
tronics firmware
as of July 1987.
_________________________________________________________________
|||||||||||||||
|||||||||||||||
The AEA and Kantronics implementations are noteworthy in
that the KISS functions were written by those vendors and
integrated into their standard TNC firmware. Their TNCs can
operate in either KISS or regular AX.25 mode without ROM
changes. Since the TNC-1 and TNC-2 KISS versions were written
by different authors than the original AX.25 firmware, and
because the original source code for those TNCs was not made
available, running KISS on these TNCs requires the installation
of nonstandard ROMs. Two ROMs are available for the TNC-2. One
contains "dedicated" KISS TNC code; the TNC operates only in the
KISS mode. The "download" version contains standard N2WX
firmware with a bootstrap loader overlay. When the TNC is turned
on or reset, it executes the loader. The loader will accept a
memory image in Intel Hex format, or it can be told to execute
the standard N2WX firmware through the "H"[3] command. The
download version is handy for occasional KISS operation, while
the dedicated version is much more convenient for full-time or
demo KISS operation.
The code for the TNC-1 is also available in both download
and dedicated versions. However, at present the download ROM
contains only a bootstrap; the original ROMs must be put back in
to run the original TNC software.
_8. _C_r_e_d_i_t_s
The combined "Howie + downloader" ROM for the TNC-2 was
contributed by WA7MXZ. This document was carefully typeset by
Bob Hoffman, N3CVL.
_________________________
[3] For "Howie", of course.
December 6, 1988
_9. _B_i_b_l_i_o_g_r_a_p_h_y
1. Tanenbaum, Andrew S., "Computer Networks" pp. 288-292.
Prentice-Hall 1981.
2. Tobagi, F. A.: "Random Access Techniques for Data Transmis-
sion over Packet Switched Radio Networks," Ph.D. thesis,
Computer Science Department, UCLA, 1974.
3. Kleinrock, L., and Tobagi, F.: "Random Access Techniques
for Data Transmission over Packet-Switched Radio Channels,"
Proc. NCC, pp. 187-201, 1975.
4. Tobagi, F. A., Gerla, M., Peebles, R.W., and Manning, E.G.:
"Modeling and Measurement Techniques in Packet Communica-
tions Networks," Proc. IEEE, vol. 66, pp. 1423-1447, Nov.
1978.
5. Lam, S. S.: "Packet Switching in a Multiaccess Broadcast
Channel", Ph.D. thesis, Computer Science Department, UCLA,
1974.
6. Lam, S. S., and Kleinrock, L.: "Packet Switching in a Mul-
tiaccess Broadcast Channel: Dynamic Control Procedures,"
IEEE Trans. Commun., vol COM-23, pp. 891-904, Sept. 1975.
7. Lam, S. S.: "A Carrier Sense Multiple Access Protocol for
Local Networks," Comput. Networks, vol 4, pp. 21-32, Feb.
1980
8. Tobagi, F. A.: "Multiaccess Protocols in Packet Communica-
tions Systems," IEEE Trans. Commun., vol COM-28, pp. 468-
488, April 1980c.
9. Bertsekas, D., and Gallager, R.: "Data Networks", pp. 274-
282 Prentice-Hall 1987.
10. Kahn, R. E., Gronemeyer, S. A., Burchfiel, J., and Kungel-
man, R. C. "Advances in Packet Radio Technology," Proc.
IEEE. pp. 1468-1496. 1978.
11. Takagi, H.: "Analysis of Polling Systems," Cambridge, MA
MIT Press 1986.
12. Tobagi, F. A., and Kleinrock, L. "Packet Switching in Radio
Channels: Part II - The Hidden Terminal Problem in CSMA and
Busy-Tone Solution," IEEE Trans. Commun. COM-23 pp. 1417-
1433. 1975.
13. Rivest, R. L.: "Network Control by Bayessian Broadcast,"
Report MIT/LCS/TM-285. Cambridge, MA. MIT, Laboratory for
Computer Science. 1985.
December 6, 1988
14. Karn, P. and Lloyd, B.: "Link Level Protocols Revisited,"
ARRL Amateur Radio Fifth Computer Networking Conference,
pp. 5.25-5.37, Orlando, 9 March 1986.
15. Karn, P., "Why Do We Even Need TNCs Anyway", Gateway, vol.
3 no. 2, September 5, 1986.
December 6, 1988